This specification relates to the use of a call gate to prevent a secure sandbox from leaking.
Secure execution of software applications is important in all computer systems. For example, bugs in an application's code, bugs in third party libraries and bugs in an operating system can open up the application to a security attack. Executing a thread in a secure sandbox provided by a host might prevent untrusted code from performing malicious activities on the host. Sandboxing can allow a thread to execute in a secure environment included in a computing system. One or more applications executing on the computing system may need to execute identified untested or untrusted code securely. For example, a computing system can enable and use a secure sandbox to execute the identified untested or untrusted code. The computing system can execute the identified code separately from other code in order to prevent the identified code from performing unwanted or, in some cases, malicious tasks in the computing system. A client application running on a host computing system can set up the secure sandbox and use it to execute the identified code. The secure sandbox can monitor the execution of the thread while providing a controlled set of resources for use by the thread. For example, a sandbox can allow a client application to securely execute a thread running applications downloaded from the Internet or third party libraries. In addition, an application that accesses and uses untrusted data can be potentially open to security attacks. The use of a sandbox can isolate and prevent the security attacks from affecting a host computer system.
A processor uses one or more interrupt descriptor tables (IDTs) to decide what to do when an interrupt occurs. In situations where more than one IDT has been created, an IDT register (IDTR) can be included in a host computing system to point to the current IDT, such as a standard or default IDT. Moreover, a device driver can modify the IDTR to instead point to another IDT, such as a custom IDT. This can allow untrusted code to operate in a secure sandbox without having access to the operating system kernel. However, in cases where the device driver passes control to the operating system kernel in order to execute trusted code, the kernel may decide to switch tasks instead of returning control to the device driver. If this happens, the other task would then be using the custom IDT. This may be considered an unwanted leaking of the sandbox from having previously included only the untrusted code to now also including trusted code.
In some situations, in order to run untrusted code securely, a second copy is made of the operating system and a secure sandbox for executing the untrusted code is included and executed in the second copy of the operating system. This requires two versions of the operating system.
In some situations, applications running on a host computing system (e.g., anti-virus software and rootkits) may modify a system service dispatch table (SSDT) (e.g., the Windows System Service Dispatch Table included in the Windows Operating System) in order to run untrusted code in a secure sandbox. However, if another thread attempts to enter the operating system kernel while the SSDT is in a modified state, an operating system error may occur that can result in the shutdown of the host computing system.
Therefore, there exists a need to allow a host computing system to run untrusted code in a secure sandbox while allowing trusted code to execute in the operating system kernel without the possibility of the operating system flagging an error and without the need for two versions of the operating system.